Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tighten the bounds on atomic Ordering in std::sys::unix::weak::Weak #79039

Merged
merged 1 commit into from
Nov 18, 2020

Conversation

thomcc
Copy link
Member

@thomcc thomcc commented Nov 14, 2020

This moves reading this from multiple SeqCst reads to Relaxed read + Acquire fence if we are actually going to use the data.

Would love to avoid the Acquire fence, but doing so would need Ordering::Consume, which neither Rust, nor LLVM supports (a shame, since this fence is hardly free on ARM, which is what I was hoping to improve).

r? @Amanieu (Sorry for always picking you, but I know a lot of people wouldn't feel comfortable reviewing atomic ordering changes)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Nov 14, 2020
@jyn514 jyn514 added the T-libs Relevant to the library team, which will review and decide on the PR/issue. label Nov 14, 2020
// invoking `mprotect`).
//
// That said, none of that's *guaranteed*, and so we fence.
atomic::fence(Ordering::Acquire);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How does the performance of the fence compare to using a 2nd load with acquire order? My understanding is that a fence inhibits more reorderings than an atomic targeting a single memory location.

@Amanieu
Copy link
Member

Amanieu commented Nov 14, 2020

You can just use Relaxed here. There's no need for a fence since we don't care about reorderings here.

@the8472
Copy link
Member

the8472 commented Nov 14, 2020

I think the concern here is multiple threads racing to load a symbol, one of them winning the race and initializing that memory and another thread then observing the new pointer. You need a happens-before relationship between using the function and the function's code being written to memory.

@Amanieu
Copy link
Member

Amanieu commented Nov 14, 2020

dlsym doesn't actually load anything, it only retrieves the address of an existing symbol.

@thomcc
Copy link
Member Author

thomcc commented Nov 14, 2020

dlsym doesn't actually load anything, it only retrieves the address of an existing symbol.

If RTLD_LAZY is specified on the loaded library, it can do actual loading I believe. RTLD_DEFAULT looks at all libraries loaded in the global namespace, including ones which may be loaded with RTLD_LAZY.

@Amanieu
Copy link
Member

Amanieu commented Nov 17, 2020

@bors r+

@bors
Copy link
Contributor

bors commented Nov 17, 2020

📌 Commit 55d7f73 has been approved by Amanieu

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 17, 2020
m-ou-se added a commit to m-ou-se/rust that referenced this pull request Nov 18, 2020
Tighten the bounds on atomic Ordering in std::sys::unix::weak::Weak

This moves reading this from multiple SeqCst reads to Relaxed read + Acquire fence if we are actually going to use the data.

Would love to avoid the Acquire fence, but doing so would need Ordering::Consume, which neither Rust, nor LLVM supports (a shame, since this fence is hardly free on ARM, which is what I was hoping to improve).

r? `@Amanieu` (Sorry for always picking you, but I know a lot of people wouldn't feel comfortable reviewing atomic ordering changes)
bors added a commit to rust-lang-ci/rust that referenced this pull request Nov 18, 2020
Rollup of 11 pull requests

Successful merges:

 - rust-lang#78361 (Updated the list of white-listed target features for x86)
 - rust-lang#78785 (linux: try to use libc getrandom to allow interposition)
 - rust-lang#78999 (stability: More precise location for deprecation lint on macros)
 - rust-lang#79039 (Tighten the bounds on atomic Ordering in std::sys::unix::weak::Weak)
 - rust-lang#79079 (Turn top-level comments into module docs in MIR visitor)
 - rust-lang#79114 (add trailing_zeros and leading_zeros to non zero types)
 - rust-lang#79131 (Enable AVX512 *epi64 variants by updating stdarch)
 - rust-lang#79133 (bootstrap: use the same version number for rustc and cargo)
 - rust-lang#79145 (Fix handling of panic calls)
 - rust-lang#79151 (Fix typo in `std::io::Write` docs)
 - rust-lang#79158 (type is too big -> values of the type are too big)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit ad6fd9b into rust-lang:master Nov 18, 2020
@rustbot rustbot added this to the 1.50.0 milestone Nov 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants